Every LISTSERV mailing list requires that an email address be defined to which all mail delivery errors are sent for disposition. The error handling address is defined by using the "Errors-To=" list header keyword.
It is strongly recommended that "Errors-To=" point to a real person's mailbox, rather than to an alias that simply dumps errors into something like
/dev/null. Mail delivery errors generally indicate that a problem exists, and it's always possible to filter out the ones that don't via procmail or by using the filtering features available in most POP mail clients. After a long enough period of time, unhandled errors can grow to a significant percentage of your server's traffic and seriously impact your production.
The internet address of the list is explicitly disallowed as an error-receiving address, and attempting to set Errors-To= to the internet address of the list will raise an error. The list should never be configured to receive its own errors as this is guaranteed to cause looping.
It should be carefully noted that there is no way to automatically discard errors without sending them to some address. "Errors-To= No" and "Errors-To= None" are both invalid settings and will cause LISTSERV to revert to the default.
LISTSERV includes a powerful auto-deletion filter that can be configured in several modes, depending on the level of error handling desired by the list owner. Currently, LISTSERV understands and can take action on errors generated by all mailers compliant with the so-called "Notary" format described in RFC1893. As more and more mailers conform to RFC1893, LISTSERV naturally will be capable of handling more and more errors intelligently.
LISTSERV has an extremely advanced loop detection heuristic that practically eliminates the chances of a mailing loop being propagated through one of its mailing lists. In general, L-Soft does not recommend that any loop-checking element be disabled, as any one missing element might let a loop through, but under certain controlled circumstances it might be needful to do this. See the
List Keyword Reference document under "Loopcheck=" for specific keyword options to turn off parts of the loop-checking feature.
LISTSERV's anti-spamming filter is built into the loop-checking heuristic. Depending on your local circumstances, it may be desirable to disable the anti-spamming filter for certain lists, particularly if the lists are confidential (and thus not visible in the global list of lists, making it extremely unlikely that a spammer would target them), if the lists are set to reject or transfer to the list moderator postings from non-subscribers (e.g., "Send= Private" or "Send= Editor"), or if your LISTSERV server is not accessible from the Internet (e.g., you're running it on an internal LAN without Internet connectivity).
One (tunable) aspect of the anti-spamming filter involves holding mail from non-subscribers for a pre-determined length of time (the default is 10 minutes) to see if further mail arrives from the same user for other lists that may trigger the anti-spamming filter. If you want anti-spamming protection, but want mail from non-subscribers to go directly to a list without being held up for this check, you can code
If you want the check to be performed, but think 10 minutes is too long to hold the messages, you can change the value for "Spam-Delay()" to the preferred number of minutes. For instance, to hold non-subscriber messages for five minutes, code
Note: You can configure the server-wide default for this "spam quarantine" feature by adding the SPAM_DELAY variable to your site configuration file and specifying the number of minutes. For instance, setting the variable to a value of 15 would set the server-wide spam quarantine default to 15 minutes, while setting it to zero disables the feature.
You can avoid the problem of a legitimate user being identified as a spammer when cross-posting to multiple lists on your server by setting up a super-list that has as its sub-lists the lists to which the user needs to cross-post. This is the only supported method for cross-posting to multiple lists if the anti-spam feature is not disabled for all the lists in question.
Note: There is no command or method to lift the 48-hour anti-spam quarantine for addresses that are identified as spammers and blocked from posting.
LISTSERV is designed to be 100% compatible with the Internet RFCs that govern how mail headers may be formatted (RFC822 et seq.), and includes a powerful RFC822 parser for this purpose. However, not all individual mail clients are compliant with RFC822, either because of poor design or because of mis-configuration. Because of this, LISTSERV postmasters may from time to time see bounces such as the example below:
The lines starting with "<W>" are warnings from the parser that indicate a non-fatal problem with one or more of the message's RFC822 headers. In this case the warnings apply to the second "Received:" header of the message, which is misformatted (it includes end-of-line characters and thus the parser treats the header as three separate RFC822 headers and attempts to parse them individually). If these were the only warnings, the message would still be accepted by LISTSERV.
However, there is a second problem in the message, and this one is fatal. The RFC822 "From:" header has a null value for the user's "userid@host" address. It is most likely that this user has decided to remove his address from his POP client's configuration in order to avoid being placed on spammers' mailing lists. However, this is not legal per RFC822, and when LISTSERV tries to determine the origin of the mail message, it can't be done. This is because the value for "From:" is invalid and there is no other header (such as "Sender:") that might be able to indicate where the message is coming from. Therefore LISTSERV writes two "<E>" (error) lines, one that says the mail origin can't be determined and a second to specify what the data was in the one origin header it could find, and bounces the message to the LISTSERV maintainer(s) for further disposition.
Note: This error commonly occurs when the inbound mail was generated with Eudora. Eudora versions 4 through 7.0.1.0 famously (and erroneously) generate duplicate Message-ID fields when using its "Send Again" feature to generate emails. The "last" commercial version of Eudora, 7.1.0.9, has finally addressed this problem.
Active address probing is available for two reasons: first, to enhance subscription renewal functionality so that no "
CONFIRM listname" response was required from subscribers in order to stay subscribed, and second, to enhance the ability of the auto-deletion feature to handle bounces that can't be parsed into something LISTSERV can recognize.
"Renewal= ...,Probe" activates this enhanced bounce processing feature, whereby subscribers are probed at subscription renewal time using the
PROBE1 mail template. The "Probe" option makes subscription renewal passive rather than reactive; no "
CONFIRM listname" response is needed from the user. In fact, the desired response from the user is to discard the message and do nothing, making the process very simple. LISTSERV also probes addresses that return mail delivery errors, and probe messages have a special signature in the return address that allows LISTSERV to uniquely identify any bouncing address, without having to understand the bounce itself.
If the probe bounces, LISTSERV first sends the PROBE2 template with a copy of the bounce, to show the user (if the account actually works in spite of the bounce) what garbage his mail system is sending people. LISTSERV then schedules a new probe for the next day, or deletes the user immediately, depending on the auto-delete policy. Every failure triggers a new daily probe until the user gets deleted or the problem gets fixed. The user can also save his subscription manually by sending a
CONFIRM listname command (this is explained in
PROBE2). This doesn't solve the underlying problem, so eventually the user should get tired of confirming in an emergency and notify his system administrators that the system is generating bounces saying (for instance) "Your message was registered at the MORONICUS mail gateway. Press F1 for more information" that cause the problem in the first place.
When used together with "Auto-Delete= ...,Full-Auto", the probe option deletes all delivery errors from bounced probes, even if LISTSERV can't understand the error. This means the list owner never ever has to see a single bounce from a probed address. The list, however, is kept clean because bad addresses are always detected. In fact, the biggest risk is that the users of the MORONICUS mail gateway will be deleted even though they do get their mail.
This being said, note carefully that all errors bounced by non-compliant mail hosts to the wrong address, and non-probe errors that are sent to the owner-listname address but are not in a format that LISTSERV can parse, will still show up in your error mailbox. If the bounce goes to the wrong address, LISTSERV never sees it and cannot probe it. If the error goes to the correct address (owner-listname) but isn't specific enough for LISTSERV to understand, while LISTSERV will be able to see it, it still won't be able to probe it. Finally, in some cases where the error is so vague (or constructed in a complicated manner that defies LISTSERV's attempts to parse it) the error may be passed to the LISTSERV postmaster, instead of to the list owner, for disposition, even if it was correctly returned to the owner-listname address.
Yet even with these restrictions, the author saw an error queue of 1300 errors/day shrink to under 50 errors/day by applying the ",Probe" parameter to seven high-volume lists, which in his opinion was much more acceptable.
If you have users who for whatever reason should not be probed, you can deactivate active probing (and any other renewal you have set for the list) with the
SET userid@host NORENEW command.
Passive probing is very similar to active probing, but it is not tied to subscription renewal. Passive probing is enabled by default for small lists (e.g., <1K subscribers) but not for large ones due to the fact that passive probing does cost additional resources and large lists are often used for one-shot mailings where it is simply not effective to use those resources to probe addresses that will not be used a second time.
Passive probing operates by turning a certain percentage of your regular list messages into transparent probes that look like a normal message but also double as a probe, rather than sending out the explicit PROBE1 template as in active probing. You enable (or tune) passive probing by adding a "
,Probe(xx)" parameter to the
Auto-Delete= keyword setting. For instance,
where "30" is the number of days to wait between probes for any given user. Subscribers with working mail systems will not see any difference, subscribers with flaky mail systems will occasionally receive a message showing that their mail bounced and saying that they should report the problem to their ISP, and of course plain bad addresses will go away.
If you have users who for whatever reason should not be probed, you can deactivate passive probing (and any other renewal you have set for the list) with the SET userid@host NORENEW command.
If a given list only has activity once in a while (e.g., a large weekly newsletter), passive probing works like this: If you have Probe(p) set in your Auto-Delete= keyword (where p is some integer value), and you have n subscribers, about ( n / p ) will receive a probe during the mailing. Normally you would want to probe 2-10% of your subscribers in this kind of scenario, so p would range from 10 to 50.
Note: LISTSERV ignores Probe(0) in list-based mail-merge jobs. Mail-merge messages are always sent as probes, and in list-based mail-merge there is no attempt made to parse the header of the list that is being used as a datastore for the mail-merge job.
On unix systems, while LISTSERV itself does support probes, probes are not supported natively by most (if not all) unix MTAs, including sendmail, etc. In order to use probing on such systems the MTA must be patched to divert incoming probe bounces to the lsv_amin mailer for delivery to LISTSERV. Otherwise incoming probes simply bounce since there is no way for the MTA to determine what to do with them.
On VMS systems, probing is supported natively if you are using L-Soft’s legacy LSMTP mailer version 1.1a or later, or any version of MX that includes support for the LISTSERV interface. PMDF® users should create a dedicated domain for LISTSERV (e.g., LISTSERV.XYZ.COM) and add a rewrite rule to redirect all traffic for that host to the LSV channel. This also simplifies the creation of new lists as with this setup, it is no longer necessary to define PMDF aliases for the lists.
It is possible to divert some of the server-level error traffic (that is to say, error traffic not specific to a given list, or errors that should never have been sent to LISTSERV to begin with) to a specified place other than the default (the non-quiet LISTSERV maintainers). This is done by adding the BOUNCES_TO= variable to your site configuration file and restarting LISTSERV.
The following specific types of traffic are routed to the BOUNCES_TO= address: spam alerts, spoofing alerts, quota errors (for sites running with the SCOPE=ISP option), and DISTRIBUTE error messages.
By default, this report is mailed to the LISTSERV maintainer. You can change the destination of these reports by adding a
CRASH_MONITOR variable to your configuration file (
SITE.CFG for NT,
SITE_CONFIG.DAT for VMS) with the email addresses to which the report should be mailed. Note that
CRASH_MONITOR replaces the entire recipient list, so make sure that all the necessary addresses are listed. This configuration variable follows the same syntax rules as POSTMASTER. Please do not add L-Soft mailboxes to
CRASH_MONITOR without checking with our support group first. While we will be happy to receive these reports, we want to make sure that they are sent to the addresses where we can process them most efficiently. In particular, these reports should never be mailed to a support engineer's personal mailbox. Instead, we use special addresses where these reports are logged for future reference.
Important: Crash reports may contain company confidential information! Before forwarding a crash report to L-Soft, make sure that it does not contain any confidential information. L-Soft will not sign non-disclosure agreements related to crash reports. If you include an L-Soft address in your
CRASH_MONITOR configuration variable, you are implicitly stating that none of the activity taking place on your server is confidential.
When reporting a crash to L-Soft, please forward a copy of the crash report with any confidential information removed or XXX-ed out. Note that the crash report is not actually mailed until LISTSERV is restarted. Crashes are usually caused by conditions which prevent LISTSERV from operating normally; furthermore, image termination may be necessary to cause the operating system to generate the traceback included in the report.
Important (Windows Only): In order for the crash report to be useful, the files
LSV.EXE and
LSV.SYM must be updated at the same time. This is done automatically if you install/update LISTSERV using the graphical installation procedure, however if you install patches manually you must ensure that both
LSV.EXE and
LSV.SYM are updated.
This feature was not provided for VM because all the information that is available is already gathered at the bottom of the console log, which is normally spooled to a maintenance userid and not accessible to LISTSERV.
Under unix, there is no portable way for an exception handler to obtain a call traceback; a system-specific debugger (which must be installed separately and often requires a separate license) must be run on the core file, which is not available until the process has aborted. LISTSERV does flush buffered log output to ensure that the listserv.log file contains all the relevant log information following a core dump.
